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Abstract 

A method for developing the require- 
ments for in-space assembly, servic- 
ing, and checkout of proposed Mars 
space transfer vehicles is dis- 
cussed. Required in-space opera- 
tions and functions are identified 
in relation to various Earth to Or- 
bit (ETO) vehicles by looking at 
the manifesting options of baseline 
Hars Space Transfer Vehicles (STV). 
Each operation is then reduced to a 
minimum complexity state resulting 
in a set of operational primitive 
functions. These primitive func- 
tions are used to assess the trade- 
offs between robotic, telerobot ic, 
and EVA operations. The study dem- 
onstrates that the complexity of 
the in-space operations remains sta- 
ble with ETO vehicle size, and 
therefore the functions, and ulti- 
mately the infrastructure required 
to support proposed missions, are 
relatively unaffected by varying 
the ETO vehicle size within the 
range considered for this study. 

Background 

In undertaking a study of this or 
any other issue the first question 
which needs to be asked is, why do 
the study at all? In the area of 
in-space assembly/servicing require- 
ments, several compelling reasons 
exist. The first is that the abil- 
ity to live and work in space is es- 
sential to the future of NASA. In— 
space operations are an inherent 
part of all spacecraft mission sce- 
narios. In generic form in-space 


operations consists of all activity 
that takes place between launch 
from the earth and landing back on 
earth or on another planet. Assem- 
bling and servicing operations are 
only subcategories of the overall 
in— space operations picture. The 
ability to assemble proposed space- 
craft, and provide essential servic- 
ing during a mission is a critical 
aspect of mission success. The cur- 
rent baseline Mars STV is a case in 
point. Current estimates indicate 
that seven launches will be re- 
quired to place all of the propel- 
lent and hardware in orbit, with 
over of fifteen months elapsing be- 
tween the first and last launch. 
During this period of time the hard- 
ware components muBt be assembled, 
stored, maintained, and inspected. 
Systems must be available to pro- 
vide power, communicate status, pro- 
vide thermal control, inspect, as- 
semble, manipulate, maneuver, and 
calibrate the vehicle. Failure to 
understand the technologies and the 
systems required to carryout these 
operations will have a direct im- 
pact on the safety of the crew, 
their ability to carry out a suc- 
cessful mission, and the total life 
cycle mission cost. 

The second reason to undertake such 
a study is the need to understand 
operations early in the mission de- 
sign process. In an era of tight 
budgets, and high expectations from 
the administration, the congress, 
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and the public , NASA cannot afford 
to wait until the later stages of 
mission planning to consider the im- 
pact of operations at the detail 
level. A look at our current space 
transportation system underscores 
this point. The orbiter was de- 
signed to achieve a given perform- 
ance level, with support operations 
being developed later in the pro- 
gram to fit the vehicle design. As 
a result of this approach extensive 
rework, refurbishment, and/or re- 
placement is required between each 
launch. The development of a de- 
tailed support operations scenario 
as an integral part of the vehicle 
design process would have identi- 
fied some of the labor intensive 
limitations imposed by the design, 
and resulted in simpler, more effi- 
cient methods for achieving the 
original design intent which was as- 
sured access to space. Some of the 
current operations and servicing re- 
quirements for mating the orbiter 
to the external tank could not be 
carried out in space with the pre- 
sent design. However, the func- 
tions which are carried out by 
these operations must necessarily 
be performed in space to mate vehi- 
cle components to propellent tanks. 
If we fail to consider the require- 
ments that each necessary function 
or operation places on the design 
of the vehicle, we will quickly 
drive total mission cost to unac- 
ceptable levels, and jeopardize 
NASA's commitment to total quality 
throughout mission life. 

The third reason for considering op- 
erations at this point is that we 
in NASA, in the early days after 
Apollo, made a promise to the pub- 
lic in return for their enthusiasm, 
excitement and support. That prom- 
ise was that we, as a nation, would 
learn to live and work in space. 
Based on current talk within the 
agency in general, and within the 
Space Exploration Initiative (SEI) 
office in particular, doubts are 
raised as to whether we still be- 
lieve we can achieve the promise. 

We owe the public a clear answer, 


not only to decide for ourselves if 
we can still keep the promise, but 
to also inform the public of the 
level of activity which will be nec- 
essary to achieve the promise if we 
believe we can do so. 

Introduction 

The primary objective of the study 
was to approach the issue of re- 
quirements from a systematic view- 
point. We did not start with a 
list of what we thought might be 
nice, nor did we start from a plat- 
form or waystation concept and work 
backwards to decide what we could 
do with the systems that were avail- 
able. We started by determining 
what needed to be accomplished. The 
expected output was a list of top 
level requirements generated from 
the operations which were dictated 
by vehicle design, ETO limitations, 
and ground based integration capa- 
bility. In addition we attempted 
to determine the minimum manpower 
which would be required to carry 
out the operations using robotics, 
telerobotics, or EVA. We attempted 
to hold to the legacy expressed in 
the Synthesis Report 1 of "ensuring 
optimum use of man-in-the-loop" . 

As the report stated "Don't burden 
man if a machine can do it as well 
or better, and vice versa". Going 
into the study we neither required 
or eliminated any method of carry- 
ing out the operations. 

The approach taken for the study 
was to first understand current 
thinking on the Space Exploration 
Initiative (SEI) strategy and op- 
tions. We then selected a baseline 
Mars STV and launch vehicle. Be- 
cause of the options which were be- 
ing developed with respect to Heavy 
Lift Launch Vehicles (HLLV) we de- 
cided to carry both a 150 metric 
tonne and a 250 metric tonne vehi- 
cle through the study. There was a 
clear understanding that both the 
ETO vehicle and the Mars STV would 
change as the program evolves. How- 
ever, sufficient thought had been 
given to current concepts that all 
of the necessary ingredients are in- 


eluded, and any changes would have 
little impact on the top level op- 
erations which would be required. 

Use was then made of information de- 
veloped under an Infrastructure 
Study ^ led by the Marshall Space 
Flight Center (MSEC), with partici- 
pation by the Langley Research Cen- 
ter (LaRC) , the Stennis Space Cen- 
ter (SSC) , the Kennedy Space Center 
(KSC), and the Lewis Research Cen- 
ter (LeRC) . This study manifested 
the baseline Mars STV on both 150 
tonne and 250 tonne vehicles. In 
addition, the study looked at the 
trade-offs which would be required, 
because of the manifest, on both 
ground based and in— space opera- 
tions. By making use of these 
trade-offs we were able to develop 
a top level operational scenario de- 
tailing the steps which must take 
place in space. Basic functions, 
and ultimately functional primi- 
tives, were generated from this op- 
erational scenario for in-space as- 
sembly of the Mars STV. These 
basic functions allowed generation 
of hardware systems and subsystems 
necessary to perform the functions. 
We then looked at both the func- 
tional primitives and the hardware 
systems and subsystems to make a de- 
termination of whether EVA or ro- 
botic techniques were best suited 
to the activity. These systems and 
subsystems became the requirements 
for any in-space infrastructure 
which will be used to carry out the 
goal of learning to live and work 
in space. 

SEI Mission Options 

Three potential mission options 
have been suggested for vehicle in- 
tegration toe the SEI program as 
follows: 

° Direct launch of fully integrated 
vehicles 

° Rendezvous and docking in LEO 
with preintegrated components 
° Assemble in space 

Direct launch of fully integrated 
vehicles imposes severe limitations 


on the design of the STV, and the 
mission duration, due to the volume 
constraints of the ETO launch vehi- 
cle shroud, and the initial mass in 
low earth orbit (IMLEO) capability. 


For purposed of this study we have 
defined rendezvous and docking as 
involving no more than two launches 
to low earth orbit with moBt hard- 
ware integration being performed on 
the ground. Two major components 
would be placed in LEO by separate 
launches and would be joined in or- 
bit by automated latching tech- 
niques. 

In-space assembly has been defined 
as involving multiple launches. 

Pre integration of large complex com- 
ponents would still be accomplished 
on the ground. However, major sys- 
tem and subsystem integration would 
be performed in space. 

Current SEI mission strategy calls 
for both piloted and cargo lunar 
missions to be completed using the 
direct launch of fully integrated 
vehicles if possible. Rendezvous 
and docking would be used if suffi- 
cient HLLV capability has not been 
developed by the mission need date. 
Mars STV' a present a different prob- 
lem. Although the cargo vehicle 
could be broken into two major com- 
ponents which allows utilization of 



Figure 1: ETO Vehicle Classes 
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rendezvous and docking techniques, 
the mass and volume requirements of 
the piloted vehicle dictates that 
in-space assembly be performed* 
Figure 1 shows both the 150 tonne 
and 250 tonne classes of ETO vehi- 
cles which were considered in the 
reference 2 Infrastructure Study. 

Assumptions 

The following assumptions were made 
prior to the start of the study* 

0 The components that were deter- 
mined to be required for an in- 
space infrastructure would be 
available as required. 

° Enabling technologies would be de- 
veloped to a sufficient level and 
in sufficient time to be incorpo- 
rated into required systems as 
needed. 

0 Current technology and the ad- 
vances which we expect to achieve 
over the next decade make telero- 
botic operation more practical 
than autonomous operation. There- 
fore, telerobotics would be con- 
sidered as the first alternative 
to EVA operations. 

0 All hardware components would be 
inspected upon arrival on orbit. 

0 All components would be secured 
to the launch structure with re- 
motely activated latches. 

0 The launch vehicle/structure 
would be capable of rendezvous 
with the infrastructure. 

° Space Station Freedom (SSF) would 
be operational during the advance 
development phase of any program 
for infrastructure development. 

0 Launch centers would be deter- 
mined by KSC based on ground proc- 
essing requirements, and resource 
availability. 

° The baseline Mars STV would be 
the 2016 reference NERVA deriva- 
tive Nuclear Thermal Rocket (NTR) 
propulsion concept, defined by 
Boeing Defense and Space Group in 
their Phase I Space Transfer Con- 
cepts final report 3 to MSFC in 
March 1991. 


Figure 2: Mars STY Baseline Concepts 
Discussion 

During the reference 2 Infrastruc- 
ture Study the baseline Mars STV 
was modified with different size 
propellent tanks for a 250 tonne 
ETO vehicle so that it would more 
effectively utilize the volume and 
IMLEO capability of the larger 
launch vehicle. Figure 2 shows the 
Mars STV concepts for each class of 
ETO vehicle considered. 

The baseline Mars STV has a mass of 
735,190 Kg which includes 525 
tonnes of propellant and 92 tonnes 
of inert mass for the propulsion 
system. Figure 3 shows the base- 
line vehicle manifesting on a 150 
tonne ETO vehicle as developed in 
the reference 2 infrastructure 
study. Figure 4 provides the same 
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Figure 4: 250t ETO Vehicle Manifesting 

information for the Mars STV as it 
was modified for a 250 tonne ETO ve- 
hicle. 

Impact of Ground Based Operations 

Recent in-house studies performed 
at KSC^ reviewed the launch facili- 
ties and ground based operational 
requirements which would be imposed 
by a National Launch System (NLS). 
These studies identified a 150 
tonne HLLV which could be used to 
launch the Mars STV. The HLLV 
ground processing time was deter- 
mined to be 79 days between 
launches. Because of the con- 
straints of other operations at KSC 
it was assumed that serial process- 
ing of the Mars STV launch vehicles 
would be required. This serial 
processing, along with the 79 day 
ground processing time, results in 
a total of 474 days between the 
time that the components included 
in the first launch arrive on or- 
bit, and the time that the compo- 
nents from the seventh launch are 
available for assembly. Since MOC 


tank #3 is manifested on the first 
launch, cryogenic hydrogen boil-off 
must be considered as a part of the 
fuel management functions which are 
identified in the study. 


Results 

Once the manifesting of the base- 
line Mars STV' s had been completed, 
a top level operational scenario 
was developed. This scenario 
looked at the major operations 
which would be necessary to accept, 
on orbit, the components from each 
launch and then assemble, mate, 
store, and maintain these compo- 
nents until the vehicle integration 
was completed. The completed state 
was defined to be, when all of the 
components, propellent, and expend- 
able had been assembled and/or 
loaded on board the Mars STV, and 
the vehicle had been fully checked 
out and prepared for engine firing 
for trans Mars injection (TMI ) . 

This included transfer of the crew 
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for final checkout and verification 
functions. 

The operational scenarios for the 
first two launches, for both a 150 
tonne ETO vehicle and a 250 tonne 
ETO vehicle are as follows x 

Operational Scenario for 150 tonne ETO Vehicle: 
Launch# 1 

0 Activate Communications / Power 
Systems 

0 Checkout / Calibrate On-Board In- 
spection Systems 
0 Inspect Components / Verify 
Health after Launch 
0 Demate MOC tank #3 from Launch 
Structure 

° Maneuver MOC tank #3 to Storage / 
Berth Location 

° Demate Remaining Components from 
Launch Structure 
° Deploy Truss Structure 
0 Verify Truss is Locked in De- 
ployed Configuration 
° Activate Monitoring System 
° Manage STV Attitude for Thermal 
Control 

° Provide Debris Protection 
Launch # 2 

° Receive, Rendezvous, Dock Compo- 
nents from Second Launch 
° Checkout On-Board Health Monitor- 
ing Systems 

° Inspect Components / Verify Health 
° Demate MEV from Launch Structure 
° Maneuver and Attach MEV to Truss 
Structure 

° Demate Aeroshell from Launch 
Structure 
° Deploy Aeroshell 

0 Inspect Aeroshell Joints and Seals 
° Repair, Reseal TPS Joints as Re- 
quired 

° Provide Inspection / Verification 
Data to Mission Control 
° Demate MOC tank #2 from Launch 
Structure 

° Manipulate MOC tank #2 into Posi- 
tion 

° Attach MOC tank #2 to Truss Struc- 
ture 

° Unberth and Manipulate MOC tank 
#3 into Position 


° Attach MOC tank #3 to STV Truss 
Structure 

° Verify All Joint Connections 
0 Make All Utility (Communica- 
tion/Power/Heaith) Connections 
° Make Fuel Connections between MOC 
tank #2 6 Manifold 
0 Perform Fuel Connection Leak Check 


Operational Scenario for 250 tonne ETO Vehicle: 
Launch #1 

° Activate Communication / Power 
Systems 

° Checkout / Calibrate On-Board In- 
spection Systems 
0 Inspect Components / Verify 
Health After Launch 
° Demate Components from Launch 
Structure 

0 Maneuver and Berth Aeroshell / 
Launch Structure 
° Deploy Truss Structure 
0 Verify Truss is Locked in De- 
ployed Configuration 
° Demate Aeroshell from Berth / 
Launch Structure 
° Deploy Aeroshell 
° Attach Aeroshell to Truss and In- 
spect Joints / Seals 
° Repair/Reseal Joints as Required 
° Provide Lighting for Remote In- 
spection 

° Provide Inspection / Verification 
Data to Mission Control 
° Activate Large Space Structure 
Control System 

° Manage STV Attitude for Thermal 
Control 

° Provide Debris Protection 
Launch #2 

0 Receive, Rendezvous, Dock Compo- 
nents from Second Launch 
0 Checkout On-Board Health Monitor- 
ing Systems 

° Demate Components from Launch 
Structure 

° Inspect Components / Verify Health 
° Maneuver and Berth TMI tank #3 
0 Demate Aft Components from Launch 
Structure 

° Maneuver Aft Components into Posi- 
tion 

0 Attach Aft Components to Truss 
Structure 
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° Verify Joint Connections 
° Make Utility (Communication, 

Power, Health) Connections 
° Unberth and Manipulate TMI tank 
#3 into Position 

° Attach TMI tank #3 to STV Assembly 
0 Make Fuel Connections between TMI 
tank #3 and Manifold 
° Perform Fu el Connection Leak Check 

During the study it was determined 
that all of the operations which 
are necessary to bring the Mars STV 
to a fully integrated condition oc- 
curred during the first two ETO 
launches. After the operations 
listed for the second launch have 
taken place for both ETO vehicle op- 
tions, we began to repeat the opera- 
tions of maneuvering, attaching, re- 
ceiving, manipulating, testing, 
etc.. For the remaining launches 
no new operations were identified. 
This led to the development of a 
list of basic operational functions 
which are repeated during the assem- 
bly and servicing phase of Mars STV 
deployment. These basic functions 
are as follows. 

Basic Operational Functions 
0 Deploy & Erect Structure 
0 Attach & (die) Assemble Components 
° Inspect Structure & Components 
° (re) Calibrate Systems & Compo- 
nents 

° Receive, Rendezvous & Dock Compo- 
nents 

° Checkout Systems & Subsystems 
0 Berth & Store Components 
0 Maneuver Components into Position 
° Manipulate Structures & Components 
0 Test & Verify Assemblies & Compo- 
nents 

0 Make Utility Connections 
0 Provide Effective Lighting 
° Communicate 
° Generate & Store Power 
° Control Large Space Structures 
° Provide Thermal & Radiation Pro- 
tection 

° Provide Debris Protection 
° Manage Cryo Fuel Transfer & Stor- 
age 

0 Manage Mission Data 


° Provide Support for Contingency 
Operations 

During the study it also became 
clear that we could address the op- 
erational functions in two differ- 
ent ways. First, we could break 
the operational functions into sev- 
eral categories such as contingency 
support operations, operational sup- 
port, and mission functional primi- 
tives. Second, we could use the op- 
erational functions to define the 
systems which make up the top level 
requirements for an in-space infra- 
structure which would be required 
for on-orbit integration of the 
Mars STV's. 

Operational Categories 

This first method of addressing the 
functions demonstrates the interde- 
pendencies and interrelationships 
of the various operational func- 
tions in each of the categories, 
with the primitives being used to 
determine the optimum method of car- 
rying out each of the functions. 

The contingency support operations 
make use of most of the infrastruc- 
ture systems, but come into play 
only when normal operational func- 
tions are out of tolerance, or when 
the crew is arriving. As an exam- 
ple component change out would oc- 
cur only when an individual system 
failed to function during in-space 
verification, or if a system had 
been damaged during operation. The 
self correcting capability would be 
utilized if a component did not fit 
as planned, or if alignment prob- 
lems were encountered because of 
tolerance buildup or thermal 
changes to the structure. These ex- 
amples also point out the need for 
early consideration of the in-space 
operations. Any problem which 
might call on the contingency sup- 
port functions needs to be consid- 
ered during the design process. 

The operational support functions 
are those which primarily involve 
control of the infrastructure and 
its activities, or provide support 
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to the functional primitives in car- 
rying out the primary mission of 
the infrastructure. 

The third category includes those 
functions which are necessary to 
complete the primary mission of an 
infrastructure, which is to assem- 
ble and service a Mars STV. These 
are the activities which require di- 
rect intervention by EVA, robotic, 
or telerobot ic techniques. Func- 
tions in this category have been re- 
duced to a set of functional primi- 
tives. The reduction in this 
manner is not intended to indicate 
ease of carrying out the function. 

In fact, just the opposite can be 
true. Some of the assembly and 
servicing activities can involve 
many of the functional primitives 
which, when combined, can become 
very difficult operations. The 
primitive functions can themselves 
be further reduced to a set of very 
difficult operations on a detail 
level. Also some of the operations 
which require reasonable simple ap- 
plication of the primitive func- 
tions can become very difficult due 
to the nature of the component be- 
ing acted on. For example the act 
of moving the TMI tanks into posi- 
tion for attachment to the truss 
structure involves simple actions. 
However, when the tanks are nearly 
full of hydrogen propellent, in a 
zero gravity environment, any move- 
ment of the tank can cause a shift- 
ing of the hydrogen propellent set- 
ting up a dynamic oscillation which 
must be damped out. In this case 
an operation which involves simple 
functions becomes very difficult to 
carry out. 

The basic operational functions in 
each of the three categories are 
listed below: 

Contingency Support Operations: 

Component Changeout 
Tool Storage 
Capture & Retrieval 
Self Correcting Capability 
Assist with Crew Transfer 


Operational Support: 

Lighting 
Communication 
Power Generation 
Power Storage 

Facility Control & Monitoring 


Data Management 

Component Storage / Berthing 


Mission Functional Primitives: 


Acquire 

Attach 

Maneuver 

Manipulate 

Berth 

Inspect 

Install 


Rotate 

Transport 

Verify 

Withdraw 

Test 

Operate 

Insert 


These mission functional primitives 
are activities which are ideally 
suited to advance telerobotic opera- 
tion. Independent studies 6 have 
looked at the timelines which would 
result from using EVA, IVA and tel- 
erobotic operations. These studies 
Indicate that total elapsed process- 
ing time would increase by 62% if 
the operations were performed tel- 
erobotically from the ground in- 
stead of using EVA. However, the 
operations can easily be performed 
telerobotically from the ground 
within the 79 day launch center for 
the HLLV. Total life cycle cost 
would decrease dramatically by us- 
ing telerobotic operations. The 
only activity occurring on-board an 
infrastructure between launches is 
assembly and servicing functions, 
or station keeping. There would be 
no impact if assembly time were dou- 
bled or tripled over what would be 
required by EVA activity so long as 
the activity could be carried out 
prior to the next launch. The stud- 
ies indicate that even with the in- 
creased time for telerobotic opera- 
tions the majority of the time 
between launches would still be 
spent in a station keeping mode. 
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Functions /System Matrix 

The second method of addressing the 
basic operational functions results 
in an extensive matrix which re- 
lates each of the functions to the 
systems and subsystems which are 
necessary to perform the functions* 
This matrix is shown in tables la 
through Id. Each of the systems or 
subsystems listed directly serves 
at least one of the functions, or 
there is some connectivity between 
the system/ subsystem and the func- 
tion. An iterative process was em- 
ployed in developing the matrix. 
First, the systems which were di- 
rectly requiredle for performing a 
function were listed. Each system 
was then reevaluated against every 
other function to determine if 
there was any connectivity to the 
other functions. In other words, 
although a function did not require 
a specific system to perform the ac- 
tivity, could that activity be en- 
hanced by using systems that are 
necessary to carry out some other 
function? 

The resulting systems/subsystems be- 
come the top level requirements for 
an in-space infrastructure to sup- 
port the assembly and servicing of 
a Mars STV. The requirements are 
independent of any current infra- 
structure concept. They provide a 
basis for evaluating concepts as to 
their ability to carryout required 
operations. These top level infra- 
structure system requirements are 
listed below: 


Required Systems 

0 Structural for supporting the 
other systems 

° Robotic Manipulators for assembly 
° Computers & Software for Data Man- 
agement 

0 Power Generation & Storage 
° Communication Hardware & Software 
° Remote Health Monitoring Sensors 
° Visual Inspection Hardware & Soft 
ware 

° Cryogenic Fuel Control 


° Docking, Berthing Mechanisms 
° Lighting Units (Fixed & Moveable) 

° Guidance, Navigation & Control 
0 Storage Mechanisms 

0 Shielding (Thermal, Debris, Radia- 
tion) 

Conclusions 

In-space assembly and servicing of 
Mars Space Transfer Vehicles will 
be required. 

The infrastructure required to 
carry out the assembly and servic- 
ing activity is determined by the 
operational functions. 

Within a given range of ETO vehicle 
sizes the infrastructure require- 
ments are independent of the launch 
vehicle sizes. 

The systems and subsystems defined 
by this study are the top level re- 
quirements for an infrastructure. 

The complexity of the operations 
which must take place in space for 
assembly and servicing of the Mars 
STV are independent of launch vehi- 
cle size. 

The frequency with which the assem- 
bly and servicing operations must 
be carried out is entirely depend- 
ent on launch vehicle size. 

The functional primitives which 
have been defined in this study are 
ideally suited for telerobotic op- 
eration. 

The 79 day launch centers required 
for ground based processing of the 
ETO vehicle is considerably longer 
than the time required for telero- 
botic assembly of the STV compo- 
nents. 

Recommendations 

There are four major recommenda- 
tions resulting from this study. 

The first recommendation should 
carry the highest priority with the 
other three carrying about the same 
weight. 
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1. We must include in-space opera- 
tional analysis as an integral part 
of current planning for all future 
missions. If we fail to consider 
detail in-space operational analy- 
sis from the conceptual mission 
stage forward we will quickly drive 
mission costs to unacceptable lev- 
els, and jeopardize NASA's commit- 
ment to total life cycle quality. 


(NAS8-37588) for Marshall Space 
Flight Center, General Dynamics 
Space Systems Division, San Diego, 
CA; December 3, 1991 

3. Wookcock, G., et al.: Space 
Transfer Concepts and Analysis for 
Exploration Missions, Phase 1 Final 
Report, Boeing Defense & Space 
Group, Advance Civil Space Systems, 
Huntsville, AL; March 1991 


2. We must conduct a more detailed 
analysis of the interdependencies 
between in-space operations and 
ground based processing. 

3. We need to carry the operational 
scenario's presented in this study 
to a more detailed level, and de- 
velop the operational timelines for 
specific mission scenario's. 

4. We should conduct system analy- 
sis studies of each proposed Mars 
STV assembly option (Free Flyer, 
Saddle, Mini Depot, Platform) with 
respect to the requirements devel- 
oped under this study, so that we 
can better understand their applica- 
bility for future use. 

In addition numerous lower level 
recommendations could be generated 
with respect to developing and re- 
fining concepts for In-Space Assem- 
bly and Servicing (ISAS) Facility 
Infrastructures. These recommenda- 
tions would cover the field from in- 
depth system/ subsystem analysis, 
through facility concept develop- 
ment, to performing detail life cy- 
cle cost analysis of various op- 
tions. Each of these are essential 
to developing our ability to live 
and work in space, and for our jour- 
ney to other planets. 
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